你是否遇過這種情況：一份測試文件拿給開發、業務、測試同仁看，每個人都有疑問，沒人能馬上理解，最後開發走自己的、測試各測各的、業務根本搞不懂在做什麼？其實問題就出在：我們寫出來的 scenario，看起來像「測試腳本」，卻沒把需求說清楚，更別說協作了。

當初在 BDD 或 實例化需求 觀念出來時，在社群中就有很多人，在整理如何寫好範例，而BRIEF 就是由軟體開發與測試實踐者在ATDD與BDD領域，為了寫出更好、更易於協作的 Gherkin 測試場景而提出的實務原則。它不是某個官方組織或特定團體獨有的框架，而是來自於敏捷實務社群對於「場景怎麼寫才有效」長期經驗的歸納和精煉。

Gáspár 和Seb多年來一直試圖為 BRIEF 概念想個好記的縮寫。在 2018 年歐洲測試會議「Writing Better BDD Scenarios」工作坊中，Gojko Adzic 也有在現場參加，聽得很投入。最後他來跟Gáspár 和Seb說，他嘗試想把一些要點縮寫成 acronym（縮寫），但沒成功。Gojko說：「Bill Wake 為 INVEST 成功設計了縮寫。」後來Gáspár 和Seb採納了他的建議，BRIEF 就這樣誕生了！

下面就是 BRIEF 的詳細介紹：

(1) B – Business Language（業務語言）

A. 精神
Scenario 是用來溝通需求、澄清規則的，不是寫給工程師自己看的技術說明書。因此，我們要用「大家都聽得懂的業務詞彙」，而不是技術細節或內部變數名稱。這能幫助業務、開發、測試，甚至是客戶一起參與討論。

B. 寫得好的範例
Scenario: Premium 會員可以下載專屬報告
Given Sarah 是一位 Premium 會員
When 她點選「下載報告」
Then 她應該可以下載 Premium 專屬報告
這裡用的是「Premium 會員」、「下載報告」這種業務上用語，任何參與者都能一眼理解。

C. 寫得不好的範例
Scenario: 用戶 id=1087 成功下載文件
Given 使用者 id=1087 已經通過 JWT 驗證
When 點擊 download_report 按鈕
Then 伺服器回傳 status code 200 並輸出檔案
這種寫法充滿「工程術語」和技術細節。業務和非技術成員看到 id、JWT、status code 可能完全無法理解需求重點。

(2) R – Real Data（真實資料）

A. 精神
使用貼近真實情境的數據和角色，而非抽象、模糊的名字或數字。這有助於激發討論、揭露假設，也方便大家發現邊界狀況。

B. 寫得好的範例
Scenario: 銀行 VIP 客戶超過 65 歲可申請專屬優惠
Given 王大明是一位 70 歲的 VIP 客戶
When 他申請高齡專屬定存方案
Then 系統應該顯示「申請成功」
「王大明」、「70 歲」、「VIP 客戶」都是容易理解且有故事感的資訊，很容易在團隊討論時「對號入座」。

C. 寫得不好的範例
Scenario: 客戶符合條件申請優惠
Given 使用者符合 VIP 條件且年齡大於 X
When 執行 apply_special_offer
Then 顯示成功訊息
這裡沒有真實人名，年齡還用 X 表示，讓人難以具象化討論，甚至容易遺漏邊界條件（例如 65 歲到底算不算？）。

(3) I – Intention Revealing（揭示意圖）

A. 精神
Scenario 應該重點說明「行為者要達成什麼目標」和「業務想解決的問題」，而不是描述操作細節或介面步驟。
這能幫助大家討論「為什麼要做這件事」，而非陷在「怎麼操作」的泥沼。

B. 寫得好的範例
Scenario: 訂單取消後自動退款給顧客
Given 顧客已支付訂單
When 訂單被取消
Then 顧客會自動收到退款
這裡 scenario 的「意圖」很明確，就是「取消訂單應該自動退款」。只聚焦在業務行為和期望的業務結果。

C. 寫得不好的範例
Scenario: 點選取消後跳轉頁面並執行 API
Given 顧客登入系統
When 點選「取消訂單」按鈕
Then 跳轉到訂單列表頁
And 呼叫 refund_order API
這寫法明顯「掉進操作細節」。你無法快速判斷這個 scenario 最重要的業務意圖，只剩下流程和技術步驟。

(4) E – Essential（關鍵必要）

A. 精神
Scenario 只保留和該規則直接相關的資訊，刪去無關的背景、設定和枝微末節。越精簡，越容易維護、溝通和理解。

B. 寫得好的範例
Scenario: 首購客戶可獲贈折價券
Given 林小慧是首次下單的新客戶
When 她完成購物結帳
Then 她會收到一張折價券
這裡 scenario 只說明規則本身。沒有多餘的登入、瀏覽商品等情境，全部聚焦在「首購 → 結帳 → 得到折價券」這條主線。

C. 寫得不好的範例
Scenario: 客戶瀏覽商品至下單並收到折價券
Given 林小慧在首頁瀏覽商品
And 她切換到優惠商品頁
And 加入商品到購物車
And 選擇信用卡結帳
And 填寫地址與發票資料
When 她點選「完成訂單」
Then 她會收到一張折價券
這裡加入太多細節，實際上和「首購送折價券」這條規則無直接關聯，只會讓 scenario 變得冗長又難維護。

(5) F – Focused（聚焦單一規則）

A. 精神
一個 scenario 只說明一個規則，避免同時描述多個行為、條件或例外。這樣 scenario 易於定位問題、討論需求，也方便日後變更。

B. 寫得好的範例
Scenario: 會員升級時扣除升級點數
Given 陳先生帳戶有 100 點
When 他升級為白金會員
Then 系統應扣除 80 點
聚焦在「升級會員會扣點數」這個單一規則。簡單、直接、易懂。

C. 寫得不好的範例
Scenario: 升級扣點且自動發送通知信並解鎖專屬優惠
Given 陳先生帳戶有 100 點
When 他升級為白金會員
Then 系統應扣除 80 點
And 發送升級成功通知信
And 解鎖白金會員專屬優惠
這 scenario 同時測試了扣點、寄信、解鎖功能，將多個規則混在一起。一旦哪一個需求有變動，scenario 就會變得難以維護或理解。